Switch to AnyCPU for libraries, migrate to slnx#187
Merged
Conversation
Replace the Platform-based architecture selection (x64/ARM64) with RuntimeIdentifier-based selection. All projects now default to AnyCPU; the correct native Windows App SDK DLLs are resolved via RuntimeIdentifier (win-x64/win-arm64) set automatically in Directory.Build.targets based on machine architecture. Changes: - Directory.Build.props: Remove Platform override that forced AnyCPU to x64/ARM64 - Directory.Build.targets: Add RuntimeIdentifier default for Windows TFM projects (net8.0+) when Platform is AnyCPU - All ~100 .csproj files: Remove <Platforms>x64;ARM64</Platforms> - Reactor.Cli: Update MirrorBinForSelfhost to resolve arch from RuntimeIdentifier (keeps bin/x64 and bin/arm64 layout) - Solution file: Update Any CPU/x86 project mappings to use Any CPU (instead of remapping to x64) - release.yml: Remove -p:Platform=x64 from build/pack (keep --runtime for publish) - coverage.yml: Replace hardcoded bin/x64 path with dynamic file lookup - Update AGENTS.md, CONTRIBUTING.md, README.md, PR template, devtools skill doc The release workflow still produces RID-specific CLI binaries (win-x64 + win-arm64) for the skill kit. The NuGet package is now architecture-neutral. Fixes #185 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Revise the AnyCPU approach based on feedback: - Libraries (Reactor, Reactor.Interop.WinForms) explicitly set Platform=AnyCPU and Platforms=AnyCPU — they produce architecture- neutral IL. - Application/test projects keep the existing x64/ARM64 platform selection via Directory.Build.props (defaults to machine arch). - WindowsAppSDKSelfContained apps need a concrete architecture for native asset resolution; this is supplied by Platform (x64/ARM64). Also migrates from Reactor.sln to Reactor.slnx: - Cleaner XML format, no per-project platform mapping boilerplate - Solution platforms reduced to x64 and ARM64 (removed Any CPU/x86) - Library projects have no platform mappings (always AnyCPU) Remove Directory.Build.targets RuntimeIdentifier logic — no longer needed since apps use Platform directly for native assets. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Each project declares its own platform requirements: - Application/test/sample projects: <Platforms>x64;ARM64</Platforms> (need concrete arch for WindowsAppSDKSelfContained native assets) - Library projects (Reactor, Reactor.Interop.WinForms): no Platforms (MSBuild defaults to AnyCPU; IL is always architecture-neutral) - Analyzers/generators (netstandard2.0): inherently AnyCPU Directory.Build.props no longer contains Platform fallback logic. When building a single app project directly, pass -p:Platform=x64 (or ARM64). Solution builds get Platform from the .slnx config. CI workflows now pass explicit -p:Platform=x64 for standalone project builds. Fix SelfTests: pure MSTest runner, no Windows App SDK dependency — set WindowsAppSDKSelfContained=false and remove Platforms. Fix .sln → .slnx migration: update FindHostExe() repo-root lookups in SelfTestBatch, TestSession, WinFormsTestSession, and CompileCommand to search for Reactor.slnx instead of Reactor.sln. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Contributor
Author
|
@microsoft-github-policy-service agree company="microsoft" |
devkanro
changed the title
StressPerf.Wpf and CmdPerf.Wpf target net10.0-windows (no WinAppSDK), so they don't need WindowsAppSDKSelfContained and can be AnyCPU. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
PerfBench.Shared, StressPerf.Shared, StressPerf.Wpf, CmdPerf.Wpf, Chat.UI, and Reactor.SelfTests no longer declare x64/ARM64 Platforms, so their slnx entries must not map to those configurations. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
codemonkeychris
requested changes
May 7, 2026
Collaborator
codemonkeychris
left a comment
codemonkeychris
left a comment
There was a problem hiding this comment.
Please check the nuget packaging - i think i ended up with x64/arm64 branches in there for the deployment of mur.exe (CLI devtool)... just check that the package generated correctly. @dotMorten has been dogfooding the nuget package from the builds, so I don't want to break him.
Contributor
Author
|
Verified locally — packaging is unchanged. NuGet package (framework): No x64/ARM64 branches — CLI skill kit (mur.exe): release.yml still publishes with
|
# Conflicts: # Reactor.sln
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Switch to per-project platform declarations: library and WPF projects default to AnyCPU,
WinUI application projects explicitly declare
x64;ARM64. Migrate from.slnto.slnx.Remove shared Platform fallback logic from
Directory.Build.props.Linked issue
Fixes #185
Key changes
Build system
<Platforms>tag, MSBuild defaults to AnyCPU<Platforms>tag — WPF has no native Windows App SDK dependencyWindowsAppSDKSelfContained=false— pure MSTest runner, no WinUI dependency<Platforms>x64;ARM64</Platforms>for WindowsAppSDKSelfContained native assetsSolution migration
CI workflows
-p:Platform=x64for standalone project builds-p:Platform=x64; replace hardcodedbin/x64path with dynamic file lookup-p:Platform=x64from solution build/pack (slnx provides it); keep--runtimefor publishCode fixes
FindHostExe()repo-root lookups in SelfTestBatch, TestSession, WinFormsTestSession, and CompileCommand to search forReactor.slnxinstead ofReactor.slnDocs
Design
Each project declares its own platform requirements — no shared magic:
Solution builds get Platform from the
.slnxconfiguration. Standalone project builds(e.g.
dotnet test tests/Reactor.Tests) require explicit-p:Platform=x64.Packaging verification
NuGet package — architecture-neutral, same structure as before:
CLI skill kit — RID-specific layout unchanged:
Test plan
dotnet build Reactor.slnx— 0 errorsdotnet test tests/Reactor.Tests -p:Platform=x64— 6819 passed, 46 skippeddotnet test tests/Reactor.SelfTests -p:Platform=x64— 670 passeddotnet build Reactor.slnx -c Release— succeedsdotnet pack src/Reactor/Reactor.csproj— correct nupkg structuredotnet publish --runtime win-x64/win-arm64— both produce valid mur.exebin/x64/mur.exemirror layout still worksRisk / breaking changes
dotnet build/test <project>without-p:Platformfor app projects will now need to either build via the solution or pass-p:Platform=x64explicitly..slnfile is removed; VS / Rider users need to openReactor.slnxinstead.